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Introduction 


The Automatic Packet Reporting 
System (APRS) is a multi-purpose 
program for the PC which makes use 
of data from the amateur packet net- 
work to provide a number of inter- 
esting and valuable functions. 


APRS embodies WB4APR’s expe- 
rience over the last 13 years using 
packet radio for real-time communi- 
cations in public service events. It 
also incorporates the capability for 
operating over non-local distances 
without use of the existing packet 
network. 


APRS accomplishes the real-time 
display of operational traffic via 
packet broadcasts and map displays. 


Historically, almost every aspect of 
HAM radio communications has as 
its root, the interest in the location of 
other stations. Look at DX maps, 
countries worked, counties worked, 
grid squares, mobile chatter; every- 
One is quite interested in where other 
stations are. 


Secondly, APRS avoids the com- 
plexity and limitations of trying to 
maintain a connected network. It 
permits any number of stations to 
participate and exchanges data just 
like voice users would on a single 
voice net. Any station that has infor- 
mation to contribute simply trans- 
mits it, and all stations receive it and 
log it. 


Packet radio has great communica- 
tion potential but so far has been best 
used for passing large volumes of 
message traffic from point to point 
or into the national distribution sys- 
tem. It has been difficult to apply 


packet to real time events where in- 
formation has a very short life time. 
Typically, several steps are involved 
in preparing and passing message 
traffic including decisions about 
routing and connectivity. 


APRS recognizes that one of the 

greatest real-time needs at any spe- 

cial event or emergency is the track- 

ing of key assets. 

-Where is the Event Leader? 

-Where are the emergency vehicles? 

— Where’s the fire? 

— Whats the Weather at various points 
in the County? 

-Where are the power lines down? 

— Where is the flood? 

-Where is the head of the parade? 

-Where are the VIP’s? 

— Where is the mobile ATV camera? 

-Where are the mobiles? 

— Where is the hurricane*? 


With the advent of affordable Global 
Positioning System (GPS) receivers, 
the powerful capabilities of APRS 
are greatly enhanced for the public 
service community (especially the 
Civil Air Patrol and disaster man- 
agement”, boaters, hikers, etc. 


The latest versions also provide spe- 
cialized support for DX cluster sys- 
tem users, and the direction finding 
capabilities are a boon to ‘fox hunt- 
ers.’ 


APRS should not be considered just 
a ‘mapping program.’ While it has a 
powerful capability to use vector 
maps (including USGS 15° grid and 
CAP 7.5°grid maps, and 
gridsquares) to display the position 
of objects, the program uniquely 
and powerfully handles databases 
such as country callsign prefixes, 


National Weather Service sites, air- 
port locations, etc. NWS informa- 
tion may be automatically via a 
landline dialer function. Headings to 
any object may be calculated and 
displayed. 


Display Screens 


There are three major display sub- 
systems and anumber of other minor 
displays. 


Latest Beacons 


This display maintains a list of the 
latest UI frame received from each 
station. In effect, this is a multi-sta- 
tion one-line broadcast message sys- 
tem. Since the lines contain the 
LATEST time of receipt, this dis- 
play shows if a station is still on line 
within the last few minutes. 


Positions 


This display maintains a separate list 
of the positions of each station. 
Each position report can also contain 
a brief comment. These lines show 
the latest time of receiving a given 
position report and give an indica- 
tion of the latency in the network 
over unreliable paths such as HF. 


They also contain Beam Heading for 
Direction Finding, and Weather 
conditions for weather reporting sta- 
tions. 


Maps 

Maps to any scale from 0.125 miles 
up to 20,000 miles can be displayed. 
Stations are instantly displayed 
when they transmit a properly for- 
matted position beacon. Stations 
with a reported course and speed are 
automatically dead-reckoned to 
their present position. A complete 
database of all the National Weather 
Service stations is built in. You can 


center the map anywhere in the 
world. 


Traffic 

In addition to the BEACON text 
which is used to broadcast informa- 
tion to all other stations on the net, 
there is an operator-to-operator mes- 
sage capability. Any station can 
send one line messages to any other 
station. On receipt, the messages 
are acknowledged and displayed on 
the bottom of the receiving stations 
screen until the operator hits the K 
key to kill them. These messages 
are ideal for station-to-station com- 
munication while remaining within 
the APRS environment. However, 
they are not as efficient as the con- 
nected protocol, and should not be 
used routinely for Rag-Chewing on 
a busy APRS net. To rapidly ex- 
change text, got to Talk mode and 
connect to the guy. 

Read Mail 

This screen shows the last 23 lines 
of messages exchanged by any sta- 


tions on the net. Is useful for 
“READING THE MAIL”. 


All Traffic Log 

This display is a time sequenced log 
of every new beacon or one line 
message sent. Beacons are logged 
the first time they are received. This 
is in contrast to the LATEST display 
which shows the most recent time of 
receipt of a beacon text. 


Heard Log 

This display maintains a count of the 
total number of transmissions from 
each station per hour. These statis- 
tics are ideal for displaying the con- 
nectivity of the network over 
varying paths, such as HF, or to see 
when stations enter and leave the 
net. 


Digipeater List 

This Display shows the full raw 
packet header so that APRS users 
can see what digipeater paths are 
being used by other stations. 


The proper use of digipeaters is im- 
portant in an APRS network. 


Station Tracking 

Although APRS automatically 
tracks mobile packet stations inter- 
faced to GPS or LORAN navigation, 
the graphic capability of the maps 
works perfectly well with manual 
tracking or with gridsquares. Any 
station on HF or VHF that includes 
his gridsquarein brackets as the first 
text in his beacon text will be plotted 
by APRS. Additionally, any station 
can place an object on his map in- 
cluding himself and within seconds 
that object appears on all other sta- 
tion displays. In the example of a 
parade, as each checkpoint with 
packet comes on line, its position is 
instantly displayed to all in the net. 


Whenever a station moves, he just 
updates his position on his map and 
that movement is transmitted to all 
other stations. 


To track other event assets, only one 
packet operator needs to monitor 
voice traffic to hear where things 
are. As he maintains the positions 
and movements of all assets on his 
screen, all other displays running 
APRS software display the same 
displays. The Tracking command on 
the P display will cause APRS to 
keep the map display always cen- 
tered on a selected object. 


Grid Squares 

APRS now also plots stations by 
gridsquares. Since four-digit grid 
squares only locate a station to the 
nearest 60 miles or so, and six-digit 
gridsquares only specify stations to 
the nearest 3 miles or so, APRS will 
not display stations reported via 
gridsquares on map ranges less than 
128 and 8 miles respectively. Sta- 
tions reported by grid squares will 
each be assigned an exact 
LAT/LON which is offset from the 
center of the grid according to an 
algorithm based on the letters of 
their callsigns. This prevents all sta- 
tions inthe same grid square from all 


being displayed on one spot in the 
center and spreads them out in the 
grid The resulting POSIT in the 
POSITION list is annotated to indi- 
cate that the position is approximate. 


Another advantage of GridSquare 
reporting in APRS is that it allows 
cautious people to participate in 
APRS without revealing their exact 
location. It is also very brief. Six 
characters vice seventeen. This is an 
advantage when reporting via MIR 
or SAREX. 


Space Applications 

APRS could be a solution to the 
effective use of orbiting terrestrial 
style packet radio digipeaters in 
space such as on the Shuttle, MIR, 
AO-21 and ARSENE. 


The problem with space digipeaters 
is the saturation on the uplink chan- 
nel which makes the use of a normal 
CONNECTED protocol impracti- 
cal. For a CONNECTED contact, a 
total of five successive and success- 
ful packet transmissions are re- 
quired 


Not only does APRS reduce this to 
one packet, but it also capitalizes on 
the most fascinating aspect of the 
amateur radio hobby, and that is the 
display on a map of the location of 
those stations. 


If all stations were encouraged to 
simply insert their LAT/LONG or 
Grid Square as the first characters of 
their beacon text, or even better, a 
compressed form of their location in 
the “TO’ field of the Unproto com- 
mand, everyone within the satellite 
footprint would see the location of 
every successful uplink. 


Since the shuttle is a rapidly moving 
object, the locations of successful 
uplink stations will move progres- 
sively along the ground track. 


All it would take to implement this 
capability is a single AMSAT news 
bulletin to ask all stations to insert 
their POSITS in their beacon text or 


Unproto string. No changes onboard 
the shuttle or MIR would be re- 
quired. 


(Ed comment: One additional 
change is perhaps some attitude ad- 
justment on the part of the user com- 
munity to be more accepting of 
digipeated UI frames. This too is a 
valid form of communication de- 
serving of access to the spaceborne 
systems.) 


Fox Hunting or Direction Finding 


APRS is an excellent tool for plot- 
ting the location of a hidden trans- 
mitter, balloon, or interfering signal. 
APRS will display the intersection 
of bearing lines from a number of 
reporting stations. To use APRS in 
this manner, each station having a 
bearing report on the direction of the 
target simply enters that bearing 
using the OPS-BeamHeading com- 
mand His station will then not only 
report his location, but also a line of 
bearing. All stations running APRS 
can simply hit the X key to display 
the intersection of these bearing 
lines. Further, if a DF vehicle has a 
GPS or LORAN device on board, he 
can be tracked and directed right to 
the location of the target. There is 
an optional Doppler DF registration 
for direct connection of a Roanoke 
or Doppler Systems DF unit for au- 
tomatically plotting andtransmitting 
instantaneous DF bearings. Please 
note that APRS uses 360 degrees for 
North and 000 to indicate that no 
direction information is available. 

Weather $ porting 
APRS position reports can also in- 
clude the wind speed and direction, 
as well as other important weather 
conditions. APRS supports a serial 
interface option to the ULTI- 
METER-II home weather station. 
With this interface, your station in- 
cludes WX conditions in your posi- 
tion report for display at all other 
stations in the network All weather 
stations show up as a bright blue 
circle, with a line indicating wind 
speed and direction. Remember that 


APRS uses 360 degrees for North 
and uses 000 to indicate that no wind 
direction is available. Each of these 
stations can be highlighted in turn 
with a single key stroke, so that all 
WX reports across the state can be 
had at a glance. 


APRS also has a database of the 
locations of all the NWS sites in the 
USA for instant display. APRS can 
also crunch a file of NWS hourly 
WX conditions and update all NWS 
stations on the map. 


Using Dumb Terminals 

Jn An APRS Network 

The simplicity and usefulness of this 
geographic capability cannot be 
over stressed. Stations running 
APRS simply move the cursor to 
where they think they are on the 
screen and their LAT/LONG coor- 
dinates are automatically transmit- 
ted to all other stations. 


Even the simplest of portable packet 
stations with dumb terminals can re- 
port their positions if a pre-printed 
map is made available to all net par- 
ticipants which has a LAT/LONG 
grid reference. The portable station 
just looks at the map and enters his 
LAT/LONG into his beacon text. 
Using the same map, he can plot 
with pins the location of all other 
stations as he sees their position re- 
ports go by. APRS also plots station 
positions based on Grid Squares. 
Eventually, we hope that all stations, 
no matter how they are using their 
TNC, will include their LAT/LONG 
or Grid Square in their Beacon Text 
so that their location is immediately 
available. 


DX Cluster System Monitoring 
APRS will grab all DX SPOTS and 
put them on the ALL list and main- 
tain a list of all DX cluster users on 
the local node in the LATEST list. 
And finally, APRS will plot the DX 
spot by callsign prefix or Grid- 
Square if given as the first four letters 
of the comment field! 


Chessboard 


To demonstrate the flexibility of 
APRS in reporting the movement of 
objects on screens in a net, I have 
drawn a chessboard map in the cen- 
ter of the Gulf of Mexico. Any two 
stations can play chess easily using 
APRS by placing pieces on the map 
using the INPUT-ADD command 
and updating their positions using 
the cursor and INSert keys! 


Monitoring stations that have also 
zoomed into the chessboard will see 
the game progress too! You should 
consider going to an unused fre- 
quency so as not to clutter an active 
APRS net. 


Protocol Techniques 


Since the objective of APRS is the 
rapid dissemination of real-time in- 
formation using packet UI frames, a 
fundamental precept is that old in- 
formation is less important than new 
information. All beacons, position 
reports, messages and display 
graphics are redundantly transmit- 
ted but at a longer and longer repeti- 
tion rate. Each new beacon is 
transmitted immediately, then 20 
seconds later. After every transmis- 
sion, the period is doubled. After ten 
minutes only six packets have been 
transmitted. After an hour this re- 
sults in only 3 more beacons; and 
only 3 more for the rest of the day! 


APRS version 5.06 implements a 
decay mechanism which adapts to 
channel usage. 


APRS Digipeaters 

To satisfy the objective of instanta- 
neous response, APRS stations are 
designed to begin operating without 
any prior knowledge of the network. 
For this reason, all APRS stations 
are initialized with the alias of 
RELAY and to send all UI frames 
via the path of RELAY. With this 
form of generic alias callsign 
(RELAY) and wildcard digipeating 
(RELAY), a mobile, or new station 


on the air does not have to know 
anything about the network in ad- 
vance, but to simply turn on his com- 
puter to be seen by adjacent nodes. 


Although digipeaters work poorly 
for AX.25 level 2 connections, they 
are ideal for APRS operation using 
UI frames only. 


The minimizing of wildcard ad- 
dressing and multiple repeats when 
not needed is the key to an efficient 
APRS network. 


In the Washington DC area and 
Chesapeake Bay area, we are estab- 
lishing a network of WIDE area 
digipeaters on the simplex packet 
frequency of 145.79. This fre- 
quency is for Keyboard QSO’s and 
all UI frame applications. Even 
leaving personal mail boxes on the 
frequency is welcome, since mail is 
posted at keyboard rates and is read 
off-the-air by the mailbox owner 
without QRM. The normal CON- 
NECTED operation of BBS’s, mail 
forwarding, file transfers, TCP-IP 
and DX clusters is discouraged! 


Wildcard Digipeating 

To make these WIDE area 
digipeaters respond to mobiles and 
new stations, all wide area 
digipeaters have the same alias of 
WIDE in addition to their normal 
FCC callsign. This second generic 
alias of WIDE adds tremendous 
flexibility to APRS networks by sig- 
nificantly extending the ranges for 
wildcard digipeating using well sit- 
uated permanent digipeaters. 


These wide area digipeaters are 
spaced several tens of miles apart so 
that they are not too close, but that 
they can hit their adjacent other 
WIDE digipeaters. 


Assuming WIDE area digipeaters 
are about 30 to 50 miles apart it is 
very easy to select an UNPROTO 
path prior to a road trip which will 
assure that your location packets 
will always get back to your home 
area. The following example shows 
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a string of digipeaters along the east 
coast. The HAM calls of SOUTH 
and NORTH are used for clarity. 


CALL: NORTH-3  NORTH-2 
NORTH-1| HOME-O SOUTH-1 
SOUTH-2 SOUTH-3 


ALIAS: WIDE WIDE 
WIDE RELAY WIDE 
WIDE WIDE 


If the mobile is going south for the 
day, and will be operating in the 
vicinity of SOUTH-3 digipeater, the 
operator can preset his UNPROTO 
path to be via WIDE,SOUTH- 
2, WIDE. 


Notice that not only will his packets 
make it back to home from the area 
of SOUTH-3, but also from the area 
of SOUTH-! since SOUTH-! will 
also respond to the first WIDE in the 
list. Similarly, stations in the vicin- 
ity of SOUTH-3 are alerted to his 
movements as heleaves home, since 
the WIDE,SOUTH-2,WIDE speci- 
fication is symmetrical. If he set the 
UNPROTO path to SOUTH-3, 
SOUTH-2, SOUTH-| in the usual 
manner, he would not be tracked at 
his homeuntil he actually arrived at 
his destination. 


As you can see, having the flexibility 
to alternate the generic aliases of 
RELAY or WIDE with other known 
sites gives a good degree of flexibil- 
ity without having to change the 
UNPROTO path while on the road. 
Using the three digipeater string, he 
can wander up to 150 miles in his 
planneddirectionandstillbetracked 

by the XYL. If he has no idea where 
he is going, he can always use the 
path of WIDE, WIDE or even 
WIDE, WIDE, WIDE and go any- 
where, but with greater QRM on the 
channel. Yes there are multiple col- 
lisions, and repeats, but the packet 
does get out to the third tier! 


Pre-emptive Digipeating 

The ultimate APRS digipeater con- 
figuration is to have modified 
digipeater code so that any digipea- 


ter hearing a UI frame with its 
callsign anywhere in the UN- 
PROTO path will pause for areason- 
able time andthen digipeat the 
packet as long as it was not pre- 
viously digipeated by any stations 
earlier in the list, 


This way, to always report your 
movements back home, you always 
place digipeaters in your UN- 
PROTO command in the reverse 
order of your travels. Your packets 
will be digipeated back to your home 
area as you enter each new digipea- 
ter in your direction of travel. For 
example, if you live in the vicinity of 
DIGI-1 below and routinely travel in 
the direction out to and including 
DIGI-3. 


DIGI-1 DIGI-2 DIGI-3 etc. 


The mobile could specify the UN- 
PROTO path of VIA DIGI-3, DIGI- 
2, DIGI-1 in order to be tracked 
anywhere all the way out to the area 
of DIGI-3. 


If only DIGI-1 hears the packet, it 
will pre-emptively digipeat the 
packet and set its digipeat flag. 


If DIGI-2 also hears the original 
packet, DIGI-2 will pause for P sec- 
onds to see if DIGI-1 repeats it. If 
so, it does nothing, since DIGI-1 
follows it in the list. If not, after P 
seconds, it digipeats the packet for 
DIGI- 1 to subsequently further 
digipeat in the normal manner. 


Similarly, DIGI-3 pauses for 2*P 
seconds to see if DIGI-2 digipeated 
the UI frame. If so, it does nothing. 
If not, after the 2*P seconds, it 
digipeats the packet. 


Even if the packet pauses and com- 
parisons are not performed, (to sim- 
plify the code) the worst case is that 
N duplicates will arrive at the desti- 
nation for all N digipeaters that si- 
multaneously heard the original UI 
frame. Since these are UI frames, 
any pauses in the network for the 
comparisons suggested are not sig- 


nificant. The extra code to do the 
pauses and comparisons only pro- 
tects against duplicates when two 
digipeaters hear the same original 
packet. 


This algorithm works perfectly well 
in reverse. If a mobile desires to 
announce his progress forward in 
the direction of his travel he can 
specify the digipeaters in the for- 
ward direction. Then using this al- 
gorithm, all of his packets will be 
repeated in the forward direction, no 
matter where he is along his route, 
but not in the backward direction. 


Until we get new UI forwarding al- 
gorithms, the general aliases of 
WIDE and RELAY will do nicely. 
If fixed, known digipeaters are 
available, even with the generic alias 
of WIDE, it is best for fixed APRS 
stations to use the digipeaters unique 
callsign instead of alias to avoid any 
ambiguity. Also avoiding the 
wildcard addresses except when 
necessary, significantly reduces 
QRM on the channel. 


APRS now has a special command 
that sets ones own station to the 
ALIAS of WIDE vice RELAY. 
This is so that an APRS station that 
is well situated, can serve as a WIDE 
digipeater. This command should be 
used with caution and with the un- 
derstanding of all stations on the net. 
Too many WIDE’s and too close 
together causes too much QRM. 


PacComm also added a new UI 
frame in their 3.2 ROM so that the 
POSITION information would be 
independent from the BText. This 
LText is just like the Beacon Text, 
except it is a separate entity with its 
own timing. This keeps the BText 
free for other applications. (particu- 
larly, for announcing WHAT your 
mobile is doing, and what symbol to 
use, etc....) This maintains the same 
distinction between BTEXT and 
POSITS that APRS already handles 
easily. 


Similarly, the LText command al- 
lows you to manually enter your 
LAT/LONG or grid square in your 
TNC, even without a GPS, so that 
TNC’s in networks will send their 
locations periodically. The LText 
permits a free text format so that it is 
compatible with any future specific 
formats (currently APRS parses 
GGA, RMC, VTG, APRS L/L, 
PACCOMM and grid squares and a 
future 8 character compressed L/L 
format) and there will probably be 
others too. 


Network Considerations 


Since NODES are so much smarter 
than digipeating, the ultimate solu- 
tion is to have the NODES do all UI 
frame routing. The APRS station 
simply sends his UI frame TO APRS 
VIA HOME; Any NODE hearing 
that transmission that has knowl- 
edge of the route to HOME, will 
send the single packet via the NODE 
network (internode, level 4) to the 
HOME node! When it arrives at the 
HOME node, it is transmitted once 
as a UI frame. With this arrange- 
ment, a mobile only has to specify 
his one intended destination, no mat- 
ter where he travels! 


DIGI/NODE COMPATIBILITY: 
Since the user should not have to 
change his digipeater path as he 
drives from one area to another, he 
should be able to specify a path that 
is compatible with both nodes and 
digipeaters. This is easily accom- 
plished by assuming that the LAST 
field in an UNPROTO digipeater list 
is the HOME NODE and should be 
the ultimate destination for the UI 
frame through any level 4 network. 
Any and all preceding fields are as- 
sumed to be digipeaters only. 


With this arrangement, the user 
could use an UNPROTO path of 
APRS VIA WIDE, HOME so that 
any generic WIDE digipeaters 
would repeat his position to their 
local area as would any WIDE 
NODES in the usual digipeater fash- 
ion. Only the node that hears the 


direct packet would also forward it 
through the network at level 4 to the 
HOME NODE. If only one field is 
included in the digipeater string, it 
would be interpreted as both a 
digipeater and a HOME destination 
without any difficulty. Digipeaters 
and NODES would digipeat it, and 
nodes (hearing it direct) would for- 
ward it at level-4. It is important that 
NODES hearing digipeated UI 
frames from other digipeaters do 
NOT enter the packet into the net- 
work, to eliminate duplication. 
Only the ones hearing the direct sig- 
nal should be responsible for doing 
the level 4 routing. 


EXAMPLE: A typical mobile just 
wanting to keep his spouse informed 
of his whereabouts might want to 
just use the UNPROTO path of 
APRS VIA HOME. Then his UI 
frames will be digipeated by the 
local HOME node or digipeater and 
will also be routed back to HOME 
by all NET- NODES along his trav- 
els. If he also wants to be seen by 
most HAMS in the areas of his trav- 
els, then he sets his path to APRS 
VIA WIDE,HOME. If he travels 
through a region that has both 
digipeaters and NODES, he might 
choose APRS VIA 
WIDE,WIDE,HOME. This way 
any areas with digipeaters would 
digipeat via. WIDE,WIDE and if he 
gets to an area with nodes which are 
aware of the path to HOME, then 
they will forward his packet there. 


Finally, since I hope to build a re- 
gional area Tracking network, the 
node should also permit the SYSOP 
to turn off other level 4 routing if he 
wants to make a dedicated network 
of APRS nodes just for tracking. 
Such a network would be swamped 
if all of the: BBS and other CON- 
NECTED protocol users began to 
use it, and the original purpose of the 
network would be defeated. 


Still, most of these APRS support 
ideas could be included in all 
NODES so that aminimum of APRS 
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tracking could be supported by ALL 
networks on all frequencies, espe- 
cially where there is not yet a dedi- 
cated APRS TRACKING 
NETWORK I think there are other 
undeveloped applications for ship- 
ping UI frames through ALL net- 
works which have not yet been 
explored. The capability should be 
there, in any case, so that experimen- 
tation can proceed. 


Using APRS for 

Space Communications 

The Automatic Packet Reporting 
System could be a solution to the 
effective use of orbiting terrestrial 
style packet radio digipeaters in the 
amateur satellite program. To date 
there have been three AX.25 1200 
baud FM transponders flown in 
space. The first was on the Space 
Shuttle STS-35, the second was on 
the space station MIR, and the third 
has been via the FM transponder 
mode of AO-21. 


The problem with a space based 
digipeater is the total saturation on 
the uplink channel which makes the 
use of a normal CONNECTED pro- 
tocol impractical. For the SAREX 
robot QSO mode, a total of five suc- 
cessive and successful packet trans- 
missions were required to constitute 
a successful contact. Of an esti- 
mated thousands of uplink stations, 
only about 250 were successful. 


Recognizing the stringent require- 
ments for success using the CON- 
NECTED protocol, provision was 
also made to recognize those sta- 
tions which were successful in get- 
ting only one packet heard onboard 
the shuttle. Over 700 stations suc- 
cessfully completed single uplink 
packets. 


APRS takes advantage of this un- 
connected, one packet mode to 
demonstrate successful uplinks to 
the shuttle. In addition, however, it 
capitalizes on the most fascinating 
aspect of the amateur radio hobby, 
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and that is the display on a map of 
the location of those stations. 


RV And Mobile HF Net 


We have begun a nation wide Boat, 
RV and APRS position reporting net 
on HF using 7.085 and 10.1515 
MHz LSB. (Yes this is in the band! 
It is the same as saying 10.147.1 
USB, but the convention on HF is to 
specify packet frequencies using the 
LSB convention.) 


All boaters and Recreational Vehi- 
cles are welcome! To see the loca- 
tions of all stations on the net, tune 
your TNC totheexact frequency and 
monitor for at least 15 minutes. 
When you first activate APRS, it 
will send out a query to all stations 
on the network for their positions. 


Packet Positions On All Frequen- 
cS 

Encourage all BBS’s, NODES, 
Servers, and stations in your area, to 
start placing their LAT/LONG in 
their beacon text using the format: 
BT!DDMM.xxN/DDDMM.xxW/... 
comments. (In order to accept this 
data in TheNet ID beacons, APRS 
will accept this position format any- 
where in the ID text. APRS will also 
plot the positions of stations report- 
ing by Grid Square surrounded by 
brackets [FM19xy]. If all packet 
stations get in that habit, then APRS 
will automatically plot a map of 
packet activity on any frequency! 


Objects 

As noted previously, anyone may 
place an object on the map and all 
other stations will see it. In their 
systems, on their P-list, the object’s 
position report will be marked with 
thelastthreelettersofthestationthat 

is currently uplinking that position 
to the net. 


A neat feature of APRS is that any 
station that has more current infor- 
mation on the location of that object 
can update its position by hooking, 
moving the cursor, and then hitting 
the insert key. Now this new station 


begins uplinking the new posit, and 
all stations, will update their P-list 
entry for that object INCLUDING 
THE ORIGINAL UPLINK STA- 
TION! The new position overwrites 
the old one so that the original sta- 
tion will now no longer uplink it. 


This cameinhandy during hurricane 
tracking. Who ever had information 
on the latest NWS EMILY position, 
uplinked it and everyone then al- 
ways saw the latest storm track with- 
out anyone in the net being 
dependent on any one station for 
updates! 


Once objects are transmitted on to 
other station map screens, they will 
remain there until that operator de- 
letes them. Even if the original sta- 
tion stops sending the object 
position, it will remain there forever. 
Once the object or station has not 
been heard from for 2 hours, it will 
fade to gray so that you know it is an 
old contact. In version 4.0 | a feature 
was added so that you can suppress 
the callsigns of old contacts. Just 
press the J command, and select 
LATEST instead of selecting any 
specific object type. 


The result will be to redraw the map 
showing ALL symbols, but only the 
calls of the recent ACTIVE stations 
less than 2 hours old. Another fea- 
ture added recently is the KILL 
function. This permits the uplinker 
of an OBJECT to KILL it from all 
displays on the net. His station will 
continue to uplink the object, but 
tagged with a special KILL flag to 
suppress its display on all screens. It 
remains in everyone’s P-lists, 
though, so they can refer back to it if 
needed. They must still manually 
DELete it from their P-list as 
needed. 


Load Sharing 

Since any station can take over re- 
porting of any objects, one approach 
is to let only one station hook every 
symbol that comes in and then he 
becomes the reporting responsibil- 


ity. The original station that up- 
linked the report in the first place 
will fall silent when it sees the report 
coming from the designated Net 
Control station. This way all posi- 
tions are reported by only one station 
on frequency, although all other sta- 
tions can still update the positions as 
needed. Remember that the last sta- 
tion to report the position of an ob- 
ject will be the one that continues to 
report it! 


Propagation Statistics 

A secondary benefit of the redun- 
dant beacons is that it operates like 
a poor-man’s chirp-sounder. Since 
APRS keeps statistics on the number 
of packets heard from each station 
over the last 24 hours, this display 
can be used to verify HF connectiv- 
ity between stations throughout the 
day. It’s like a free-bee radio check 
every 15 minutes everywhere! 
After watching APRS statistics for 
just a day, or so, the daily variations 
in propagation conditions to all sta- 
tions is visible at a glance. Further 
improvements in connectivity is 
possible by changing frequency 
bands during the solar day. By sav- 
ing statistics on each band in a dif- 
ferent file, the APRS user can use 
this data to optimize his connectivity 
at any time of day or location. 


Weather Reporting 

All stations on the net can be ap- 
prised of unusual weather condi- 
tions by any station placing a 
weather symbol on the map. Just 
like stations, weather symbols will 
be dead reckoned between reports. 
In this way APRS is ideal for report- 
ing the movements of hurricanes and 
tropical storms. There are over a 
dozen different weather symbols for 
this type of weather reporting. Sec- 


ondly, APRS has an optional inter- 
face routine for automatically re- 
porting the wind speed, direction, 
temperature and rainfall from the 
ALTIMETER-II home weather sta- 
tion. All stations with this interface 
show up on the maps as a large blue 
DOT with a line indicating the wind 
direction and speed. Their position 
report also includes the temperature 
and the rainfall. Similarly, any sta- 
tion can select to use the Weather 
station symbol for his station, and 
can manually enter his wind speed 
and direction for display on the net. 


Waterway Net Operations 

It is recommended that all Waterway 
Net participants that are HF packet 
capable begin reporting their posi- 
tions on the HF APRS nets. No 
changes to the existing voice net on 
7068 are required! Since APRS will 
be operating continuously, 24 hours 
a day, it will provide a reliable and 
continuous background reporting of 
most stations. This will free up the 
voice net for passing of more voice 
traffic, and for position reports from 
non packet stations. One APRS sta- 
tion should volunteer daily to uplink 
the voice position reports into the 
network from his display by placing 
them on his screen as OBJECTS. 
Once these reports are being up- 
linked into the APRS net, any other 
APRS station can assume reporting 
responsibility for that OBJECT (sta- 
tion) simply by uplinking a later re- 
port. If the original station 
uplinking an OBJECT hears a later 
report, it will update its screen with 
the new report and will no longer 
report on that OBJECT since an- 
other station has taken reporting re- 
sponsibility for that OBJECT. This 
enables stations to pass off APRS 
reporting responsibilities and keeps 


the network from being dependent 
on specific full time stations. 


Differential Correction 


Tom Clark (W3IWD) ... installed a 
Differential GPS transmitter in the 
Washington DC area transmitting 
30 second DGPS data on the APRS 
frequency. APRS GPS mobiles can 
now obtain accuracies to 5 meters or 
so. We are pleased to report that the 
RTCM- 104 format works perfectly 
well with APRS and with TNC’s. 


Although this is an excellent demon- 
stration. and there are surely HAM 
applications that can take advantage 
of the DGPS accuracy, APRS is 
probably not one of them. First, 
APRS is not concerned with NAVI- 
GATION accuracy, because a) no 
maps are that accurate (with DGPS 
you can make ‘em so!), and b) the 
purpose of APRS is to inform others 
of mobile locations over a wide VHF 
area, NOT to the nearest 15 feet. 
(APRS formats do maintain posi- 
tions to 60 foot precision ) Secondly, 
A mature APRS net involved in a 
special event. or activity, can proba- 
bly NOT handle the QRM from 30 
second RTCM transmissions. 


In the long term, the DGPS data 
should probably be transmitted 
MORE OFTEN and on another fre- 
quency, OR be remotely controlled 
such that it can be requested by a 
mobile user on demand, but silenced 
most of the time. Transmitting less 
often is meaningless due to latency 
of the data The only application of 
DGPS that I can think of is to keep 
track of golfcarts at a hamfest, and 
be able to see who’s booth they are 
at. I will probably incorporate a 
?RTCM? format in APRS to permit 
stations to request DGPS data. 


